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Interworking ISDN Call Control User Information with SIP 
Abstract 


The motivation and use cases for interworking and transporting User- 
to-User Information (UUI) from the ITU-T Digital Subscriber 
Signalling System No. 1 (DSS1) User-user information element within 
SIP are described in RFC 6567. As networks move to SIP, it is 
important that applications requiring this data can continue to 
function in SIP networks as well as have the ability to interwork 
with this ISDN service for end-to-end transparency. This document 
defines a usage (a new package called the ISDN UUI package) of the 
User-to-User header field to enable interworking with this ISDN 
service. 


This document covers interworking with both public ISDN and private 
ISDN capabilities, so the potential interworking with QSIG will also 


be addressed. 


The package is identified by the new value "isdn-uui" of the 
"purpose" header field parameter. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7434. 
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Overview 


This document describes a usage of the User-to-User header field 
defined in [RFC7433] to enable the transport of UUI in ISDN 
interworking scenarios using SIP [RFC3261]. Specifically, this 
document discusses the interworking of the following items, which are 
call control related: ITU-T Recommendation Q.931 DSS1 User-user 
information element [Q931], ITU-T Recommendation Q.957.1 DSS1 User- 
to-User Signalling (UUS) supplementary service [0957.1], and ITU-T 
Recommendation Q.763 User-to-User information parameter [Q763] data 
in SIP. Today, UUI is widely used in the Public Switched Telephone 
Network (PSTN) in contact centers and call centers that are 
transitioning away from ISDN to SIP. 


This usage is not limited to scenarios where interworking will occur. 
Rather it describes a usage where interworking is possible if 
interworking is met. That does not preclude its usage directly 
between two SIP terminals. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Summary of the ISDN User-to-User Service 
1. The Service 


ISDN defines a number of related services. Firstly, there is a user 
signalling bearer service that uses the information elements / 
parameters in the signalling channel to carry the data and does not 
establish a related circuit-switched connection. For DSS1, this is 
specified in ITU-T Recommendation 9.931, Sections 3.3 and 7 of 
[Q931]. Secondly, it defines a User-to-User Signalling (UUS) 
supplementary service that uses the information elements / parameters 
in the signalling channel to carry additional data but that is used 
in conjunction with the establishment of a related circuit-switched 
connection. This reuses the same information elements / parameters 
as the user signalling bearer service, with the addition of other 
signalling information, and for DSS1 this is specified in ITU-T 
Recommendation Q.957.1 [0957.1]. 
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ISDN defines three variants of the UUS supplementary service as 
follows: 


UUS1: User-to-User Information exchanged during the setup and 
clearing phases of a call by transporting DSS1 User-user 
information elements within call control messages. This in itself 
has two subvariants, UUS1 implicit and UUS1 explicit. In UUS1 
implicit, it is the presence of the user signalling data itself 
that constitutes the request for the service. UUS1 explicit uses 
additional supplementary service control information to control 
the request and granting of the service, as in UUS2 and UUS3. As 
a result, UUS1 explicit also allows the requester to additionally 
specify whether the parallel circuit-switched connection should 
proceed if the UUS1 service cannot be provided (preferred or 
required); 


UUS2: DSS1 User-user information elements exchanged from the 
sender’s point of view during call establishment, between the DSS1 
ALERTING and DSS1 CONNECT messages, within DSS1 USER INFORMATION 
messages; and 


UUS3: DSS1 User-user information elements exchanged while a call is 
in the Active state, within DSS1 USER INFORMATION messages. 


The service is always requested by the calling user. 


This document defines only the provision of the ISDN UUS1 implicit 
supplementary service to interworking scenarios, this being the most 
widely deployed and used of the various ISDN User-to-User services, 
and is indeed the one that matches the requirements specified in 
[RFC6567]. 


The above comes from the ISDN specifications defined for public 
networks. There is a parallel set of ISDN specifications defined for 
private networks (QSIG). These specifications do not define a UUS1 
implicit supplementary service. However, implementation of such a 
UUS1 implicit supplementary service for private networks can readily 
be constructed in a proprietary fashion based on the specifications 
for public networks, and evidence suggests that some vendors have 
done so. On this basis, there is no reason why this package cannot 
also be used to support interworking with such a private network 
service, on the assumption that the constraints are exactly the same 
as those for the public network. 
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The ISDN UUS1 service has the following additional characteristics as 
to the data that can be transported: 


The maximum number of octets of user information that can be 
transported is 128 octets plus a protocol discriminator. It is 
noted that some early ISDN implementations had a limitation of 32 
octets, but it is understood that these are not currently 
deployed. While this package does not prohibit longer data 
fields, the mechanism at any interworking point discards data 
elements that are too long to handle. The handled length can 
normally be assumed to be 128 octets. 


The content of the user information octets is described by a 
single octet protocol discriminator (see Table 4-26 of ITU-T 
Recommendation Q.931) [0931]. That protocol discriminator may 
describe the protocol used within the user data, the structure of 
the user data, or leave it entirely open. Note that not all 
values within the protocol discriminator necessarily make sense 
for use in the ISDN User-to-User service, as the content is 
aligned with the protocol discriminator that appears at the start 
of all DSS1 messages (see Table 4-1 of ITU-T Recommendation 0.931) 
[0931]. The protocol discriminator value has no impact on the 
interworking capability. 


Only a single piece of UUI data can be transported in each 
message. 


The ISDN service works without encryption or integrity protection. 
The user trusts the intermediate network elements, and therefore 
the operator of those elements, not to modify the data and to 
deliver all the data to the remote user. On a link-by-link basis, 
message contents are protected at Layer 2 by standard cyclic 
redundancy check mechanisms -- this allows loss on a link-level 
basis to be detected but does not guard against fraudulent attacks 
on the link itself. This does not prevent the use of additional 
encryption or integrity protection within the UUI data itself, 
although the limit on the size of the UUI data (protocol 
discriminator plus 128 octets) will restrict this. 
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4. 


-2. Impacts of the ISDN Service on SIP Operation 


The ISDN service has the following impacts that need to be understood 
within the SIP environment. 


Call transfer: ISDN call transfer cancels all ISDN User-to-User 
supplementary services. In the ISDN, if User-to-User data is 
required after call transfer, then UUS3 has to be renegotiated, 
which is not provided by this SIP extension. The impact of this 
restriction on the SIP environment is that UUI header fields 
cannot be exchanged in transactions clearing down the SIP dialog 
after call transfer has occurred. 


Conference: ISDN conferencing allows the user to still exchange 
User-to-User data after the conference is created. As far as UUS1 
is concerned, it is not permitted. The ISDN three-party 
supplementary service is similar in many ways to conferencing but 
is signalled using a different mechanism. This means that on 
clearing, the controller using UUS1 implicit does have the choice 
of sending data to either or both remote users. Because SIP 
conferencing cannot completely emulate the ISDN three-party 
supplementary service at the served user, UUS1 implicit is not 
possible. 


Diversion: When ISDN diversion occurs, any UUS1 User-to-User data is 
sent to the forwarded-to-user (assuming that the call meets 
requirements for providing the service -- this is impacted by the 
explicit service only). If the type of diversion is such that the 
call is also delivered to the forwarding user, they will also 
receive any UUS1 User-to-User data. 


Relation to SIP-T 


A method of transport of ISDN User-to-User data is to use SIP-T 
[RFC3372] and transport the UUI information end-to-end (as part of an 
ISUP message or QSIG message) as a MIME body. If the SIP-T method of 
encapsulation of ISDN instead of interworking is used, this is a 
reasonable mechanism and does not require any extensions to existing 
SIP-T. However, if true ISDN interworking is being done, and 
therefore SIP-T would not otherwise be used, this approach is not 
reasonable because then implementation of the many elements of the 
ISUP syntax would be required to understand one element of data. 
Instead, the better approach is to interwork the ISDN User-to-User 
data using the native SIP UUI transport mechanism, the User-to-User 
header field. The rest of this document describes this approach. 
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Transition Away from ISDN 


This interworking usage of the SIP UUI mechanism will likely begin 
with one UA as an ISDN gateway while the other UA is a native SIP 
endpoint. As networks transition away from ISDN, it is possible that 
both UAs could become native SIP endpoints. In this case, there is 
an opportunity to transition away from this ISDN usage to a more 
general usage of [RFC7433]. 


The SIP UUI mechanism provides a way to achieve this transition. As 
an endpoint moves from being an ISDN gateway to a native SIP 
endpoint, and a future package for some form of enhanced UUI has been 
standardized, the endpoint can carry the UUI data both as ISDN and as 
the future package in parallel and in the same messages or in 
different messages depending on the needs of the application. This 
will permit the other endpoint to use the UUI according to the ISDN 
UUI package if it is an ISDN gateway or according to the future 
package if it is a native SIP endpoint. 


ISDN Usage of the User-to-User Header Field 


This document defines the package for the ISDN interworking of UUI 
that interoperates with ISDN UUS, a supplementary service in which 
the user is able to send/receive a limited amount of information to/ 
from another ISDN user over the signalling channel in association 
with a call to the other ISDN user. 


Two examples of ISDN UUI with redirection (transfer and diversion) 
are defined in [ANSII] and [ETSI]. 


One objective of the design of this package has been to keep the 
functionality at the interworking point as simple as possible. Asa 
result, there is also only one encoding value specified. 


Responsibility for respecting the limits has been transferred to the 
end UA. If an interworking point is reached, and the limitations of 
the ISDN (see Section 3.1) are not met, then the UUI data will not be 
transferred, although the SIP request will otherwise be interworked. 
This is rather than have the interworking point attempt to resolve 
the non-compliance with the limitations of ISDN. 


The general principals of the UUI mechanism package are, therefore, 
as follows: 


The sending application is expected to limit their sending 
requirements to the subset provided by the ISDN User-to-User 
service. 
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The SIP UA will not allow the reception of more than one 
User-to-User header field relating to the "isdn-uui" package in 
the same SIP request or response; it will only allow it ina 
request or response of the appropriate method (INVITE or BYE). 
What happens to User-to-User header fields relating to other 
packages is outside the scope of this document. 


An interworking point trying to interwork UUI data that is too 
long will discard the UUI data but proceed with the interworking. 
There is no notification of such discard back to the sending user. 
If the SIP user knows that it is interworking with the ISDN, then 
the UUI application at the SIP endpoint should limit its 
communication to packets of 128 octets plus the protocol 
discriminator, with the knowledge that discard will occur if it 
does not. The UUI application at the SIP endpoint has complete 
control over what occurs. It should be noted that this was 
exactly the envisaged operation when early ISDN implementations 
that only supported 32 octets interworked with those supporting 
128 octets. It also corresponds to the interworking with ISDNs 
that do not support the supplementary service at all, as discard 
will occur in these circumstances as well. Note that failure to 
include the User-to-User data into the ISDN SETUP message (when 
discard occurs) will result in the service being unavailable for 
the remainder of the call when UUS1 implicit operation is used. 


7. UAC Requirements 


The User Agent Client (UAC) MUST meet the requirements of [RFC7433] 
in addition to the requirements defined in this document. 


The UAC MUST only use this UUI mechanism extension package in 
association with the initial INVITE method and the BYE method 
relating to an INVITE dialog. Usage on transactions associated with 
any other type of dialog, or on methods not associated with a dialog, 
is precluded. Usage on other methods within the INVITE dialog, and 
on re-INVITE transactions with the INVITE dialog, is also precluded. 


If the UAC wishes to use or permit the sending of UUI data at any 
point in the dialog, the UAC MUST include in the INVITE request for 
that dialog a User-to-User header field. The UAC SHOULD set the 


"purpose" header field parameter to "isdn-uui". Non-inclusion of the 
"purpose" header field parameter is permitted, but this is primarily 
to allow earlier implementations to support this package. This 


initial header field constitutes the implicit request to use the UUI 
service and is, therefore, included even when there is no data except 
the protocol discriminator octet to send at that point in time. 
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The UAC MUST NOT include the User-to-User header field with a 
"purpose" header field parameter set to "isdn-uui", or with no 
"purpose" header field parameter, in any message of an INVITE dialog 
if the original INVITE request did not include the User-to-User 
header field, either with a "purpose" header field parameter set to 
"isdn-uui" or with no "purpose" header field parameter included. 


When sending UUI for the ISDN UUI package, if the "purpose" header 
field is included, the UAC MUST set the User-to-User "purpose" header 


field parameter to "isdn-uui". The UAC MUST NOT include more than 
one User-to-User header field for this package in any SIP request or 
response. 


When receiving UUI, when multiple User-to-User header fields are 
received in the same response with the "purpose" header field 
parameter set to "isdn-uui", or with no "purpose" header field 
parameter, or with some combination of these, the UAC MUST discard 
all these header fields. There are no mechanisms for determining 
which ones are the intended UUI data, so all are discarded. 


The application designer will need to take into account the ISDN 
service restrictions; failure to do so can result in information 
being discarded at any interworking point with the ISDN. This 
document makes no further normative requirements based on those 
constraints because those constraints may vary from one ISDN to 
another. It is reasonable to expect that a limitation of 128 octets 
(plus a protocol discriminator) can be imposed by the ISDN; 
therefore, UUI data longer than this will never reach the destination 
if such interworking occurs. Note that the 128-octet limit (plus a 
protocol discriminator) applies before the encoding (or after the 
decoding) using the "hex" encoding. The "hex" encoding is defined in 
[RFC7433]. 


A "uui" option tag for use with the UUI mechanism extension is 
defined in [RFC7433]. Because the service is UUS1 implicit for the 
ISDN User-to-User service, the inclusion of the "uui" option tag ina 
Supported header field conveys no additional information over and 
above the presence, in the INVITE request, of the User-to-User header 
field with the "purpose" header field parameter set to "isdn-uui". 
While there is no harm in including the "uui" option tag, and 
strictly it should be included if the extension is supported, it 
performs no function. The presence of the "uui" option tag in the 
Require header field of an INVITE request will cause the request to 
fail if it reaches a UAS or ISDN interworking gateway that does not 
support this extension; such usage is allowed but will produce 
results that are inconsistent with the mechanisms defined in the ISDN 
UUS supplementary service. 


Drage & Johnston Standards Track [Page 9] 


RFC 7434 ISDN Call Control UUI January 2015 


8. 


UAS Requirements 


The UAS MUST meet the requirements of [RFC7433] in addition to the 
requirements defined in this document. 


The UAS MUST only use this UUI mechanism extension package in 
association with the initial INVITE method and the BYE method 
relating to an INVITE dialog. Usage on transactions associated with 
any other type of dialog, or on methods not associated with a dialog, 
is precluded. Usage on other methods within the INVITE dialog, and 
on re-INVITE transactions with the INVITE dialog, is also precluded. 


The UAS MUST NOT include the User-to-User header field with a 
"purpose" header field parameter set to "isdn-uui", or with no 
"purpose" header field parameter, in any message of an INVITE dialog 
if the original INVITE request did not include the User-to-User 
header field, either with a "purpose" header field parameter set to 
"isdn-uui" or with no "purpose" header field parameter included. 


The UAS MAY include the User-to-User header field in responses to the 
initial INVITE request, or the BYE requests or responses for the 
dialog, only where the original INVITE request included a 
User-to-User header field with the "purpose" header field parameter 
set to "isdn-uui" or where no "purpose" header field parameter was 
included. When sending UUI for the ISDN UUI package, the UAS SHOULD 
set the User-to-User "purpose" header field parameter to "isdn-uui". 
Non-inclusion of the "purpose" header field parameter is permitted, 
but this is primarily to allow earlier implementations to support 
this package. 


When sending UUI for the ISDN UUI package, if the "purpose" header 
field is included, the UAS MUST set the User-to-User "purpose" header 
field parameter to "isdn-uui". The UAS MUST NOT include more than 
one User-to-User header field for this package in any SIP request or 
response. 


The "isdn-interwork" value for the "purpose" header field parameter 
was used in documents that led to the publication of the present 
document. Although these documents had no other status than "Work in 
Progress", this value is implemented by some vendors. While not 
defined by this document, implementations could find it useful for 
interoperability purposes to support parsing and interpreting 
"isdn-interwork" the same way as "isdn-uui" when receiving messages. 


Where the UAS is acting as a redirect server, the UAS MUST NOT 
include the User-to-User header field in the header URI parameter in 
a 3xx response to an incoming request. 
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When receiving UUI, when a User-to-User header field is received in a 
request that is not from the originating user with the "purpose" 
header field parameter set to "isdn-uui", or with no "purpose" header 
field parameter, the UAS MUST discard this header field. 


When receiving UUI, when multiple User-to-User header fields are 
received from the originating user in the same request with the 
"purpose" header field parameter set to "isdn-uui", or with no 
"purpose" header field parameter, or with some combination of these, 
the UAS MUST discard all these header fields. There are no 
mechanisms for determining which ones are the intended UUI data, so 
all are discarded. 


9. UUI Contents 


These requirements apply when the "purpose" header field parameter is 
set to "isdn-uui" or when there is no "purpose" header field 
parameter. 


Processing for User-to-User header fields sent or received with 
values other than this value are outside the scope of this document, 
and the appropriate package document for that value applies. 


The default and only content defined for this package is "isdn-uui". 
When sending UUI, the sending SIP entity MAY, but need not, include a 
"content" header field with a value set to "isdn-uui". A receiving 
SIP entity MUST ignore a received User-to-User header field if the 
"content" header field parameter is present and the value is some 
other value than "isdn-uui". 


The default and only encoding defined for this package is "hex". 
When sending UUI, the sending SIP entity MAY, but need not, include 
an "encoding" header field with a value set to "hex". A receiving 
SIP entity MUST ignore a received User-to-User header field if the 
"encoding" header field parameter is present and the value is some 
other value than "hex". 


When sending UUI, the sending application MUST include a protocol 
discriminator octet, conforming to Table 4-26 of ITU-T Recommendation 
Q.931 [Q931], as the first octet of the UUI data. It is up to the 
receiving application what it does with this value. This document 
places no other normative requirement on the use of the protocol 
discriminator; it is required at interworking gateways to allow 
mapping into the appropriate fields in the ISDN protocols; otherwise, 
the usage is entirely up to the application and is outside the scope 
of this document. Valid values are identified and documented by 
ITU-T, and there is no IANA registry for these values. 
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EIs 


Considerations for ISDN Interworking Gateways 


ISDN interworking gateways MUST support the requirements defined for 
UAS and UAC operation. 


ISDN interworking gateways MUST support only the "isdn-uui" package 
on dialogs that are interworked. 


ISDN interworking gateways will take octet-structured data from the 
ISDN side and encode it using the "hex" encoding scheme defined in 
[RFC7433] for inclusion as the UUI data in the User-to-User header 
field. In the reverse direction, it will take valid UUI data 
according to the "hex" encoding scheme and decode it to octet- 
structured data to send to the ISDN side. 


When mapping data content from the ISDN to SIP signalling, or from 
SIP signalling to the ISDN, the gateway needs to assume that all 
content is octet-structured binary, irrespective of the value of the 
received protocol discriminator. There are no requirements in the 
ISDN to ensure that the content matches the value of the protocol 
discriminator; the application usage sorts out any discrepancy. The 
same applies to the ISDN protocol discriminator as the first octet of 
the UUI data, as defined in Table 4-26 of ITU-T Recommendation Q.931 
[Q931]; the interworking gateway will not perform any additional 
checking of this value. 


A "uui" option tag for use with the UUI mechanism extension is 
defined in [RFC7433]. The option tag is not interworked at an ISDN 
interworking gateway. The ISDN interworking gateways MUST NOT take 
the omission of the "uui" option tag in a received INVITE request to 
indicate that interworking of a received header field is not to be 
performed. 


Coding Requirements 


This document defines "isdn-uui" as a new value of the User-to-User 
"purpose" header field parameter. The following ABNF adds to the 
production in [RFC7433]: 


pkg-param-value =/ "isdn-uui" 


This document defines "isdn-uui" as a new value of the User-to-User 
"content" header field parameter. A content value of "isdn-uui" 
indicates that the contents have a first octet that is a protocol 
discriminator (see Table 4-26 of ITU-T Recommendation Q.931 [Q931]) 
followed by UUI data that can be subject to a length limitation 
(before encoding or after decoding) that is generally 128 octets. 
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The following ABNF adds to the production in [RFC7433]. 
cont-param-value =/ "isdn-uui" 
12. Media Feature Tag 


This document defines the new media feature tag "Sip.uui-isdn". This 
feature tag indicates that this ISDN UUI package is supported by the 
sender, and its usage is entirely in accordance with [RFC3840]. This 
document makes no additional provisions for the use of this feature 
tag. 


13. IANA Considerations 


Per this document, the following row has been added to the "UUI 
Packages" subregistry of the SIP parameter registry: 


Value: isdn-uui 


Description: The associated application is being used with 
constraints suitable for interworking with the ISDN User-to-User 
service, and therefore can be interworked at ISDN gateways. 


Reference: RFC 7434 


Per this document, the following row has been added to the "UUI 
Content" subregistry of the SIP parameter registry: 


Value: isdn-uui 


Description: The associated contents conform to the content 
associated with the ISDN User-to-User service. In the presence of 
the "purpose" header field parameter set to "isdn-uui" (or the 
absence of any "purpose" header field parameter), this is the 
default meaning and therefore need not be included in this case. 


Reference: RFC 7434 


This document defines the following media feature tag, which has been 
added to the features.sip-tree of the Media feature tags registry: 


Media feature tag name: sip.uui-isdn 


ASN.1 Identifier: 1.3.6.1.8.4.x 
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Summary of the media feature indicated by this tag: This media 
feature tag when used in a Contact header field of a SIP request 
or a SIP response indicates that the entity sending the SIP 
message supports the package "uui-isdn". 


Values appropriate for use with this feature tag: none 


Examples of typical use: Indicating that a mobile phone supports 
Single Radio Voice call Continuity (SRVCC) for calls in the 
alerting phase. 


Related standards or documents: RFC 7434 


Security Considerations: Security considerations for this media 
feature tag are discussed in Section 11.1 of [RFC3840] 


14. Security Considerations 


This document contains no specific requirements in regard to security 
over and above those specified in [RFC7433]. However, since this 
capability is designed to interwork with the ISDN, the general 
security considerations of SIP to ISDN User Part (ISUP) interworking 
defined in [RFC3398] apply. Any SIP/PSIN gateway implementing the 
ISDN User-to-User service should not blindly trust ISUP from the 
PSTN. In general, the overlying use case will define the security 
measures required. The underlying User-to-User header field 
extension provides a number of tools that can meet certain security 
requirements. 


Information that might otherwise reveal private information about an 
individual, or where a level of authenticity needs to be guaranteed, 
may need a higher level of protection and may indeed not be suitable 
for this package, particularly taking into account the statement in 
the following paragraph. 


As this capability is defined to interwork with the ISDN, if the ISDN 
forms part of the route, any usage needs to be aware that the 
security level of the ISDN service may be lower than the security of 
the SIP service. The ISDN security is itself not definable on an 
end-to-end basis and exists on a hop-by-hop basis. This can be high 
in some places (e.g., it can require physical access to a secure 
building) and in other places it can be low (e.g., the point where an 
ISDN access enters a building). If this level of security is not 
sufficient, then either a different package or indeed a different 
method of data transfer needs to be selected by the application user. 
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